home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940369.txt < prev    next >
Internet Message Format  |  1994-11-13  |  23KB

  1. Date: Sun,  6 Nov 94 04:30:19 PST
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: List
  6. Subject: Ham-Digital Digest V94 #369
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Sun,  6 Nov 94       Volume 94 : Issue  369
  11.  
  12. Today's Topics:
  13.                        9600bd radio's ?? NOT !
  14.                   Amateur Packet <-> Linux software.
  15.                         Amtor/Pactor BBS Freqs
  16.                       CD Recording of Mod Types
  17.                Computer <--> Modem <--> Modem <--> TNC
  18.                       Decode ACARS with a modem?
  19.                                MFJ1270C
  20.             NoCal OO goes after Packet BULLetins  (2 msgs)
  21.                      pk-88 birdie on 145.05 help?
  22.                              unsubscribe
  23.                            WINSOCK <-> AX25
  24.  
  25. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  26. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  27. Problems you can't solve otherwise to brian@ucsd.edu.
  28.  
  29. Archives of past issues of the Ham-Digital Digest are available 
  30. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  31.  
  32. We trust that readers are intelligent enough to realize that all text
  33. herein consists of personal comments and does not represent the official
  34. policies or positions of any party.  Your mileage may vary.  So there.
  35. ----------------------------------------------------------------------
  36.  
  37. Date: Fri, 4 Nov 1994 07:41:03 GMT
  38. From: gary@ke4zv.atl.ga.us (Gary Coffman)
  39. Subject: 9600bd radio's ?? NOT !
  40.  
  41. In article <joopv.783722779@etprs.phys.tue.nl> joopv@etprs.phys.tue.nl () writes:
  42. >Since some time now several manufacterers of ham radio equipment offer
  43. >'9600 bd ready' vhf/uhf transceivers. I got one of these for some tests,
  44. >and was very surprised with the results. This is a brandnew mobile uhf rig,
  45. >FM only, from one of the 'big three' brands. The price is in the $500-$600
  46. >range.
  47.  
  48. Don't be coy, name names. We want to know what this radio is so we
  49. can avoid it.
  50.  
  51. Gary
  52.  
  53. -- 
  54. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  55. Destructive Testing Systems |    we break it.     | emory!kd4nc!ke4zv!gary 
  56. 534 Shannon Way             |    Guaranteed!      | gary@ke4zv.atl.ga.us
  57. Lawrenceville, GA 30244     |                     | 
  58.  
  59. ------------------------------
  60.  
  61. Date: Mon, 31 Oct 94 10:29:16 Mst
  62. From: ve6hf@ve6hf.ampr.ab.ca (Jefferson Makus)
  63. Subject: Amateur Packet <-> Linux software.
  64.  
  65. gary@ke4zv.atl.ga.us (Gary Coffman) writes:
  66.  
  67. > In article <390p3d$c9u@homer.alpha.net> jachim@myhost.subdomain.domain (Matth
  68. > >I'm looking for a software package to allow me to use packet radio to
  69. > >log into my computer running Linux.  From what I understand, it seems it
  70. > >should be something like getty (or agetty or uugetty), right? 
  71. > >The problem is, the data is first intercepted by the TNC.  I've heard
  72. > >a little about KA9Q and its derivatives. Would this be what I need?
  73. > It could be *exactly* like getty, in fact you can use getty. Just
  74. > treat the TNC as a modem and wire up the DCD line. The TNC asserts
  75. > that when a connection occurs, and will signal getty to spawn a
  76. > login process, just as a telco modem would. So after you connect 
  77. > to the TNC, you'll see a login: prompt sent back to you. Then 
  78. > proceed as normal for a telco login. 
  79. > Of course since you're on an open radio channel, don't login
  80. > to any account you want to keep secure since everyone monitoring
  81. > will see the password. Setup a radio login that you wouldn't
  82. > mind *anyone* using, and set permissions accordingly. Visual
  83. > applications won't run worth spit over the slow half duplex
  84. > link, so you'll need to run vi in ex mode, and forget about
  85. > doing anything with X.
  86. > If you need client/server functionality, then you'll want
  87. > to use the kernel AX25 driver and TCP/IP with a KISS TNC. 
  88. > That's a much higher level of complexity to set up, but gives 
  89. > you more flexibility.
  90. > Gary
  91. > -- 
  92. > Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  93. > Destructive Testing Systems |    we break it.     | emory!kd4nc!ke4zv!gary 
  94. > 534 Shannon Way             |    Guaranteed!      | gary@ke4zv.atl.ga.us
  95. > Lawrenceville, GA 30244     |                     | 
  96.  
  97.  
  98. I tryed that but I have the system lock up.  Reason for that was that I 
  99. was that I run a program PACICO that get headers off of the bbs and puts 
  100. them in the newsgroup rec.radio.amateur.edmonton.alledm (USENET).  
  101. Be careful that you are just using the tnc or the tty for 1 operation 
  102. would be my suggestion :)
  103.  
  104. ---
  105.            You may reply to: ve6hf@ve6hf.ampr.ab.ca   
  106.  
  107. ------------------------------
  108.  
  109. Date: 1 Nov 1994 04:20:15 GMT
  110. From: ppiercey@random.ucs.mun.ca (Paul Piercey)
  111. Subject: Amtor/Pactor BBS Freqs
  112.  
  113. Jim Cummings (jcumming@dgim.doc.ca) wrote:
  114. : Hello:
  115.  
  116. : Would someone be kind enough to list the Amtor/Pactor BBS frequencies and 
  117. : locations?
  118.  
  119. : Thank you
  120.  
  121. : Jim, VE3XJ@VA3TCP
  122.  
  123. I think there is a file at ftp.ucsd.edu with a fairly up-to-date listing 
  124. of these freqs. I can't confirm this but I have seen a few copies of this 
  125. type of file at different sites and this site seems well stocked with HAM 
  126. files.
  127.  
  128. Hope this helps.
  129.  
  130. --
  131. ============================================================================
  132. Paul J. Piercey (VO1HE)
  133.  
  134. Packet Address                      VO1HE@VO1SIG.#ENF.NF.CAN.NA
  135. Internet Address                    ppiercey@random.ucs.mun.ca
  136.                                     ppiercey@morgan.ucs.mun.ca
  137. ============================================================================
  138.  
  139. ------------------------------
  140.  
  141. Date: 5 Nov 1994 22:40:58 GMT
  142. From: khansen@ix.netcom.com (Kevin Hansen)
  143. Subject: CD Recording of Mod Types
  144.  
  145. Advertised in the "First October Issue 1994" of Amateur Radio Trader
  146. is a 2-CD (audio) set of modulation types.  The copy claims 71
  147. emmissions with a running time of 2.5 hours.  The price is $75 which 
  148. includes worldwide registered airmail (the seller is in Germany).
  149.  
  150. Have you heard of this item (or, better yet, used it)?
  151.  
  152. Kevin Hansen
  153. WD6FFB
  154.  
  155. ------------------------------
  156.  
  157. Date: Fri, 4 Nov 1994 07:57:32 GMT
  158. From: gary@ke4zv.atl.ga.us (Gary Coffman)
  159. Subject: Computer <--> Modem <--> Modem <--> TNC
  160.  
  161. In article <39ccia$f80@bingnet1.cc.binghamton.edu> bd27015@bingsuns.cc.binghamton.edu (David J. Graff) writes:
  162. >Jeff Okleberry (jeffo@syseng.slc.unisysgsg.com) wrote:
  163. >: I have a new computer which does not have any free modem ports, but does
  164. >: have an internal modem.  I have an extra stand alone modem and I was
  165. >: wondering if it is possible to use the modems so I can commuicate with
  166. >: my TNC (Figure 2).
  167. >
  168. >as for what you are suggesting you'd need a computer on the other end
  169. >to run the second modem then the TNC.....the TNC cannot control the
  170. >modem...
  171.  
  172. The TNC doesn't have to control the modem. Once you set the modem up,
  173. if it's a Smartmodem(tm) it'll stay that way unless the power burps,
  174. if it's a dumb modem, it'll stay that way period.
  175.  
  176. >:  ____________            _____               _____            _______
  177. >: |            |  RS-232  |     |  Telephone  |     |  RS-232  |       |
  178. >: |  Computer  |----------|Modem|-------------|Modem|----------|  TNC  |
  179. >: |____________|          |_____|             |_____|          |_______|
  180. >
  181. >:                                   Figure 2            
  182. >
  183. >
  184. >: My second question is it possible to do the same thing in Figure 2 with
  185. >: two computers?  A follow-on question is can I use my house's
  186. >: internal telephone  wiring or do
  187. >: I need to run a direct link between the two modems?
  188. >
  189. >you just can't do it....the modems themselves need to have line
  190. >voltage to "see" a carrier 
  191.  
  192. No they don't. Standard modems don't use the telco battery voltage
  193. at all. They generate tones, and decode tones, any pair of wires will
  194. do to conduct the tones from one to the other. You don't want to use
  195. your existing telco wiring because the moden loading will signal the
  196. central office with an off hook condition. That'll busy your line,
  197. and eventually drop a trouble card on your line. But there's no problem
  198. using a dry pair to connect the modems.
  199.  
  200. Just remember that you have to initially set one modem to originate
  201. mode, and the other to answer mode with the ATO and ATA commands.
  202. Set carrier timeout to never, and strap DTR high on the connector.
  203.  
  204. Gary
  205. -- 
  206. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  207. Destructive Testing Systems |    we break it.     | emory!kd4nc!ke4zv!gary 
  208. 534 Shannon Way             |    Guaranteed!      | gary@ke4zv.atl.ga.us
  209. Lawrenceville, GA 30244     |                     | 
  210.  
  211. ------------------------------
  212.  
  213. Date: Fri,  4 Nov 94 00:56:39 PST
  214. From: Ted_Eugene_Viens@cup.portal.com
  215. Subject: Decode ACARS with a modem?
  216.  
  217. >In article <9411010320.AA14440@chop.isca.uiowa.edu> prusso@chop.isca.uiowa.edu
  218. >(Peter Russo) writes:
  219. >>From: prusso@chop.isca.uiowa.edu (Peter Russo)
  220. >>Subject: Decode ACARS with a modem?
  221. >>Date: 31 Oct 1994 20:26:28 -0600
  222. >
  223. >>I was just wondering-
  224. >
  225. >>Does anyone know if it is possible to decode ACARS signals transmitted by an
  226. >>airplane with an ordinary 2400 bps modem?
  227. >>I'd like to use a modem instead of buying an expensive decoder.
  228. >
  229. >No. ACARS is MSK, which cannot be handled by a non-MSK modem. Are there
  230. >"expensive decoders" available for ACARS? I'd be wary, since the airlines can
  231. >transmit basically anything they want in an ACARS packet, so they can do any
  232. >kind of shorthand or code they please. You may demodulate it, but you may not
  233. >be able to read it.
  234. >
  235. >
  236. >
  237. > -------------------------------------------------------------
  238. > Eric Jacobsen                              ericj@primenet.com
  239. > EF Data Corp.                              Vox: (602)968-0447
  240. > 2105 W. 5th Pl.                            Fax: (602)921-9012
  241. > Tempe, AZ  85281
  242. >
  243. > My employer snickers heartily at my opinions.
  244. > -------------------------------------------------------------
  245. >
  246. Quite the opposite.  Universal radio makes a couple of $400 decoders that
  247. include ACARS.  I own the M1200 computer plug-in card decoder.  ACARS
  248. transmissions are very encoded, however the M1200 manual spends several
  249. pages explaining the short-hand and Universal sells an inexpensive pamphlet
  250. that goes even further.  With a little practice, you can do better than
  251. an 80% comprehension of intercepted messages.  Of course, most of the
  252. messages are pretty mundane.  Still, it is always fun to look in on something
  253. not really intended for you.  Standard disclaimers, I don't have any
  254. relationship with Universal Radio beyond a happy customer and it sure would
  255. be dull to invest in an ACARS decoder if you didn't live near an airport
  256. or major air route....
  257. Bye...  Ted..
  258.  
  259. ------------------------------
  260.  
  261. Date: 6 Nov 94 00:18:51 GMT
  262. From: pandora!daniel (W. Daniel)
  263. Subject: MFJ1270C
  264.  
  265. Hi,
  266.  
  267.         Thanks for the info on the MFJ-1270-C. Can you tell me how much does
  268. the MFJ-46 cost? Does the 1270C run the 1.1.8 TAPR firmware? I suppose there is
  269. no easy way to upgrade it ourselves?
  270.  
  271.         Secondly, does the 1270B support a mailbox? If so how? Thanks.
  272.  
  273. 73 de 9V1ZV,
  274. Daniel
  275.  
  276. p.s.    I've been using a 1270B for a little while with an IC-22A. I have
  277.         received some reports of loss of audio (not carrier) when trasmitting
  278.         in high power mode. Is there any chance of this being RF induced? The
  279.         funny thing is that this seems okay on other channels.
  280. -- 
  281. +-------------+-------------------------------------+
  282. | Daniel Wee  | daniel%pandora@csah.com             |
  283. | 9V1ZV       | daniel.wee@f516.n600.z6.fidonet.org |
  284. | UUCP1.12j   | Packet: 9V1ZV @ 9V1VS.SGP.AS --     |
  285. +-------------+-------------------------------------+
  286.  A public-opinion poll is no substitute for thought
  287.                   -- Warren Buffet --
  288.  
  289. ------------------------------
  290.  
  291. Date: 3 Nov 1994 17:41:05 -0800
  292. From: rwilkins@ccnet.com (Bob Wilkins  n6fri)
  293. Subject: NoCal OO goes after Packet BULLetins
  294.  
  295. Steve Wolf (sww@csuohio.edu) wrote:
  296.  
  297. : But is is broadcasting none the less.
  298.  
  299. : I think it was Todd Little that that quoted the definition of broadcasting.
  300.  
  301. : From Part 97.3(a) ... (10) ... Broadcasting - Transmissions intended for
  302. : reception by the general public, either direct or relayed.
  303.  
  304. : Clearly, a BBS phone port with a annonymous check-in allows the public access
  305. : to relayed transmissions.  There are LOTS of phone ports that allow
  306. : anonymous check-ins.
  307.  
  308. : So, originators of bulletins which are sent by any means to a BBS that has
  309. : a public phone port that are not about amateur radio would fall under
  310. : broadcasting.
  311.  
  312. : Broadcasting does not require a one-way transmission.  It would appear that
  313. : an ax.25 connection between two stations can still be use for broadcasting.
  314.  
  315. : (Bet we are going to move on and say that a bulletin about quilting was
  316. : targeted solely at the amateur population.  Let me guess ... ANY bulletin
  317. : entered on packet is to be assumed to be aimed solely at the amateur radio
  318. : population.)
  319.  
  320. I can't tell if I am a victim of dry Cleaveland humor or you are truly 
  321. serious...
  322.  
  323. In the event you are serious in your interpretations of the rules, do you 
  324. plan to close down your operations on tcp/ip and public pbbs stations?
  325.  
  326. Following your logic even a personal third party message in transit
  327. through your stations that could be seen by a non-amateur scanner
  328. enthusiast with a tnc would then be considered broadcasting. Many members
  329. of the All Ohio Scanner Club use tncs for entertainment and information
  330. gathering. Since it is your station that is being received by the public. 
  331. why is the originating station in California guilty of Broadcasting? 
  332.  
  333. I hope you never have to provide emergency message service to the public
  334. during a disaster. Many amateur groups set up packet stations at Malls to
  335. provide Health and Welfare messages to the public so they can contact
  336. family and friends outside the disaster area. This is an Amateur Service 
  337. that has always provided good will to the public. Doing this in front of 
  338. the public and even allowing the public to type their short messages into 
  339. a computer is a broadcasting violation of your interpretation. Are you sure?
  340.  
  341. Most of us try to interpret the rules to allow us the most latitude in
  342. _operating_  our stations even bending them a little to allow new modes of
  343. communications. 
  344.  
  345. Hank is right when he talks about unconnected UI frames. I have seen many
  346. Beacon Broadcasts that could be reasonably called broadcasts as defined. 
  347. These beacons are generaly of the non amateur _Save our State_ or _Jesus
  348. Saves_ or _Pro Gun_ types of quasi-political slogans. This is the area 
  349. that the OOs and ARRL need to address and educate within our ranks. 
  350.  
  351. Lets see ... I have set my Beacon Text to _Cookies are good with Milk_ and
  352. I am digipeating this every seven minutes through four digipeaters in the
  353. area. Who is violating which rules? 
  354.  
  355. Bob
  356.  
  357.  
  358. -- 
  359.      Bob Wilkins                     work    bwilkins@cave.org
  360.  Berkeley, California                home    rwilkins@ccnet.com
  361.      94701-0710                      play    n6fri@n6eeg.#nocal.ca.usa.noam
  362.  
  363. ------------------------------
  364.  
  365. Date: Fri, 04 Nov 94 20:31:13 GMT
  366. From: jangus@skyld.grendel.com (Jeffrey D. Angus)
  367. Subject: NoCal OO goes after Packet BULLetins 
  368.  
  369. In article <1994Nov3.115023.22992@news.csuohio.edu> sww@csuohio.edu writes:
  370.  
  371.   > 
  372.   > Dave Horsfall (dave@eram.esi.com.au) wrote:
  373.   > : In article <1994Oct29.000208.29686@news.csuohio.edu>,
  374.   > :     sww@csuohio.edu (Steve Wolf) writes:
  375.   > : 
  376.   > : | All bulletins are broadcasting.  They are sent in many directions.  When be  > : | forwarded, the receiving station did not ask for them.  The sending station  > : | has no expectation that the receiving BBS will read or reply to them.
  377.   > : 
  378.   > : Dunno about your neck of the woods, mate, but here down under the sender
  379.   > : presents a brief list of bulletins, and the receiver is invited to
  380.   > : accept or reject them...
  381.   > 
  382.   > When being forwarded?  Really?  How does that work?  I can understand the
  383.   > user being queried but as the quote says, we are talking about forwarding.
  384.   > 
  385.  
  386.   As am I. I receive bulletins from my feed station. The first thing it
  387.   does is send "SB LOSERS @ ALLCAS < $1234_XYZ" and waits for an "OK" from
  388.   me. If I alread have a copy of it (based on the bid and wars fought over
  389.   that in a different thread) I send "NO" and it proceeds to try sending me
  390.   something else instead.
  391.  
  392.   From the questions, answers and other comments you make about this, it
  393.   seems to me that you do not even have a TNC nor have you spent anytime
  394.   monitoring a channel. If you have, some of this would be self evident.
  395.  
  396.   Face it Steve, you've stepped on your dick. Now quietly put it back in
  397.   your pants, zip up and stop asking others to come by and step on it as
  398.   well.
  399.  
  400.   Repeat after me: "It is NOT broadcasting."
  401.  
  402.         Broadcasting as the FCC intended it to be interpratated
  403.         was to prevent the amateur radio ops from competing with
  404.         the commercial broadcasters. You know, people like KFI,
  405.         KNX, WCBS and the likes.
  406.  
  407.   For those of you that must know, I forward lots of messages. All types.
  408.   Personal, Bulletins and Traffic. For the others that looks at how many
  409.   as a chest-thump, you don't need to know *how* many.
  410.  
  411.   In addition, I forward e-mail in and out of this medium (internet and
  412.   UUCP) as well. Lots.
  413.  
  414.  
  415.   73 es GM from Jeff
  416.  
  417. --
  418. "1935 will go down in history. For the first time, a civilized nation has
  419. full gun registration. Our streets will be safer, our police more efficient,
  420. and the world will follow our lead into the future." - Adolf Hitler 
  421.  
  422.  Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM Internet: jangus@skyld.grendel.com
  423.  US Mail: PO Box 4425 Carson, CA 90749       Phone: 1 (310) 324-6080
  424.  
  425. ------------------------------
  426.  
  427. Date: 4 Nov 1994 20:05:42 GMT
  428. From: gh@christa.unh.edu (Gary Hurd)
  429. Subject: pk-88 birdie on 145.05 help?
  430.  
  431. Hi all, name here is Gary.  I have an AEA PK-88 tnc and sometimes use it 
  432. on 145.05.  The unit produces a very bad birdie on that freq and makes my 
  433. Kenwood tr-7600 virtually deaf.  I am currently using 145.61 with no 
  434. problems but would still like to clear up the problem.  The tnc is about 
  435. 3 and a half years old with no upgrade of the eprom.  I am currently 
  436. using tcpip so I don't care about the upgrade unless it would clear up 
  437. the problem.  Tnx es 73 de Gary / WR1U @ KA1OU.NH
  438. TCP/IP wr1u@wr1u.ampr.org  [44.52.7.40
  439.  
  440.  
  441.  
  442. -- 
  443. Gary Hurd gh@christa.unh.edu
  444. Packet address WR1U @ WB1DSW.NH
  445. TCP/IP wr1u.ampr.org [44.52.7.40
  446. PETRA ROCKS ON!
  447.  
  448. ------------------------------
  449.  
  450. Date: 5 Nov 94 22:44:15 GMT
  451. From: Doughengst@aol.COM
  452. Subject: unsubscribe
  453.  
  454. unsub doughengst@aol.com ham-digital
  455.  
  456. ------------------------------
  457.  
  458. Date: Mon, 31 Oct 1994 22:11:08
  459. From: roschews@panix.com (Rob Roschewsk)
  460. Subject: WINSOCK <-> AX25
  461.  
  462. Has anyone come up with a winsock.dll that talks to TCP/IP over AX25?????
  463.  
  464. de KA2PBT
  465.  
  466. ------------------------------
  467.  
  468. Date: Sat, 05 Nov 1994 12:53:50 -0500
  469. From: rsnyder@astro.ge.com (Bob Snyder)
  470.  
  471. References<391b4f$t7g@qualcomm.com> <395vb8$h2c@hpbab.wv.mentorg.COM>, <396g3i$38k@qualcomm.com>
  472. Subject: Re: using passwords over packet
  473.  
  474. In article <396g3i$38k@qualcomm.com>, karn@servo.qualcomm.com wrote:
  475.  
  476. > I think I do. It's really very simple; if the protocol does not hide
  477. > the user data but merely authenticates it, then it is legal under Part
  478. > 97 even if the authentication is based on strong cryptographic
  479. > techniques.  No rule changes or waivers should be required.
  480.  
  481. Would it be hiding the user data, or hiding any data, since it's all being
  482. transmitted?  A password isn't encrypted or obscuring the meaning; if my
  483. password is "jwdjfc32," then that's the literal meaning of what I
  484. transmitted.  Similarly under S/key the password means what it means,
  485. nothing, except a secret bit of shared information.  Except that it's only
  486. good one time. :-)
  487.  
  488. However, authenticating packets based on a shared secret is somewhat
  489. different.  There you have a hash (probably MD5) representing the data
  490. being encrypted.  If you use something like DES or IDEA to encrypt this,
  491. then you are obscuring that content, because it does have a meaning other
  492. than itself, and it can't decrypted by anyone other than the parties
  493. holding the key to that session.  Of course, anyone can generate their own
  494. copy of the hash, thus replicating what has been encrypted, but the
  495. content is still obscured.
  496.  
  497. > I think this is true even if the authentication cannot be verified by
  498. > a third party who does not know the shared secret key. This is
  499. > admittedly a disadvantage of using a keyed one-way hash function in
  500. > the way I've described. But I think it's more than offset by the
  501. > considerably improved performance as compared with RSA signing each
  502. > and every packet (which could be verified by anyone with the
  503. > corresponding public key).
  504.  
  505. But under a public key system, everyone who wants it can have your key,
  506. and thus it can be argued that you aren't obscuring the content, since
  507. anyone who wants to can decode it and get the hash.  The penalty, as you
  508. say, is performance.  Symetric encryption is around a 1000x faster than
  509. public key encryption.  But given that most traffic today happens at 1200
  510. or 9600 baud, I would think that most machines should be able to keep up
  511. at those speeds.  The swIPe paper details workstation performance, and as
  512. I recall they got fairly good response time out of it.  Most people don't
  513. have workstations doing packet, but most people also aren't running packet
  514. anywhere near Ethernet or T1 speeds.
  515.  
  516. Bob
  517. -- 
  518. Bob Snyder N2KGO
  519. rsnyder@astro.ge.com
  520.  
  521. ------------------------------
  522.  
  523. Date: Sat, 05 Nov 1994 12:56:26 -0500
  524. From: rsnyder@astro.ge.com (Bob Snyder)
  525.  
  526. References<390p3d$c9u@homer.alpha.net> <1994Oct30.232012.19369@ke4zv.atl.ga.us>, <1994Oct31.231925.434@systech.mhs.oz.au>
  527. Subject: Re: Amateur Packet <-> Linux software.
  528.  
  529. In article <1994Oct31.231925.434@systech.mhs.oz.au>,
  530. serge@systech.mhs.oz.au (Serge Burjak) wrote:
  531.  
  532. > Investigate a package called skey, I am trying to find an ftp source. It
  533. appears
  534. > to generate one time codes from a secret key and can be used on open channels
  535. > for just this type of application as a front end to most *nix programs.
  536.  
  537. ftp://ftp.crimelab.com/ is one location for it.
  538. -- 
  539. Bob Snyder N2KGO
  540. rsnyder@astro.ge.com
  541.  
  542. ------------------------------
  543.  
  544. End of Ham-Digital Digest V94 #369
  545. ******************************
  546.